The GUI update (Part II) - Technology tree Today we will speak a bit about the work in progress of the Technology tree, and the main GUI style/philosophy evolution. The visual style is evolving and becoming more mature. The aim is to be as functional as possible, and also be pleasant to interact with, always having in mind the limitations of making it work in our engine. This is why we bet for a neutral and sober look that helps to focus on the relevant elements, without the distraction of possible decorative elements. This is not easy to decide, because the tradition of video-games is very rich in decorative GUI elements, and I'm sure that many of you would prefer having screws and rust in the corners of the metal panels and cables hanging everywhere in the GUI. Me too. Sometimes. I believe that once the GUI is completely functional, there will be some minimal decoration and this kind of fantasy, but this will be another chapter if it ever happens. We are paying a lot of attention to the readability in general, according to the AAA standards of the WCAG. So the contrast with the panels and the font is increased quite a lot compared to previous mock-ups by simply using a contrast checker. Also the font size is increased by 2pt so it is more comfortable to read. Anyway, the user will have control of the font size in the options menu. Bear in mind that the next mock-ups are a work in progress, and we still developing our standards, so some colours and solutions can vary through further iterations.
More particle optimisations Allaizn Rseding's recent optimisations of the particle system (FFF-322) made particles much more lightweight than they were before, but it still left particles as rather complex beasts. A quick summary of the possible actions a particle can make during it's update: Move their own position. Advance their animation to another frame. Land in water and apply a trigger. Apply another trigger with a certain frequency. Remove themselves from the game world once their life time ends. What makes this complex is that triggers are general purpose systems that can do all kinds of things, including creating and destroying entities, fire, smoke and other particles as well as playing sounds or recursively applying even more triggers. In other words: applying a trigger is an "anything can happen" situation and thus totally unpredictable, which in turn makes optimisations extremely hard.
The multiplayer megapacket Twinsen Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy. Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening. The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped. The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.
New pathfinding algorithm Oxyd Last week we mentioned the change to make biters not collide with each other, but that wasn’t the only biter-related update we released this past week. Somewhat coincidentally, this week’s updates have included something I’d been working on for a few weeks before – an upgrade to the enemy pathfinding system.
Hello, It's Earendel back for another electric adventure. You got your first look at Fulgora in FFF-398. (If you haven't read that already please read that first.) Now let's take a look at the new planet's mechanics.
Hello, we usually show finished stuff in Friday facts these days, but I personally always liked to have a peek behind the curtains and see the (temporary) mess there. This motivated me to do some kind of overview of how the overall expansion development felt from my perspective. If you are like me, you might appreciate it. Our story starts in February 2021 with FFF-365 when we announced the plan to do the expansion pack.
